r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

⚠️ Warning ⚠️

• These commits modify submodules.

The Miri subtree was changed

cc @rust-lang/miri

Nominating for T-lang FCP. This stabilizes the AVX512 target features which is a per-requisite for stabilizing the AVX-512 intrinsics tracked in #111137.

Can you also send a PR to update https://github.com/rust-lang/reference/blob/master/src/attributes/codegen.md#x86-or-x86_64?

⚠️ Warning ⚠️

• Some commits in this PR modify submodules.

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• llvm-mistake (Stabilize the avx512 target features #138940 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@rfcbot reviewed

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot reviewed

☔ The latest upstream changes (presumably #139914) made this pull request unmergeable. Please resolve the merge conflicts.

I discovered a related mistake in LLVM. Basically

• avx512f - GCC and Intel implies only avx2, LLVM also does fma and f16c
• avx512fp16 - GCC and Intel implies only avx512bw, LLVM also does avx512dq and avx512vl

I have filed llvm/llvm-project#136209

For avx512f, this requirement is probably justified (see this comment). We just need to ensure that fma and f16c are required for avx512f in std_detect. I have sent a PR (rust-lang/stdarch#1781).

But we need to settle the avx512fp16 business.

This has the potential to generate invalid code (even in safe Rust, e.g https://godbolt.org/z/d3M674nY6 - here only avx512fp16 is enabled, but LLVM is generating vaddph.128, which is not available without avx512vl). Even if #140002 passes though, this invalid codegen will persist, as it is an LLVM issue. So essentially we have 2 options

• Don't adhere to Intel's spec. We say that avx512fp16 implies avx512vl in rustc_target/target_feature.rs, and only enable it in std_detect when avx512vl is available. This is safe, with the caveat that if Intel releases a CPU with avx512fp16, but not avx512vl (currently none exist) Rust will just not detect avx512fp16 there.
• Delay the stabilization of avx512fp16 for now. We wait for the upstream LLVM issue to be fixed (which I believe will take a long time).

I don't think we have to delay the stabilization of any other avx512 target feature.

cc @rust-lang/lang
cc @rust-lang/wg-llvm

☔ The latest upstream changes (presumably #139309) made this pull request unmergeable. Please resolve the merge conflicts.

@rfcbot concern llvm-mistake
@rustbot labels +I-lang-nominated

Good catch. We'll be sure to discuss.